Method And System For Monitoring A Supply-Chain

ABSTRACT

A method of monitoring supply chain activity throughout supply chain sites includes extracting, at each site, supply-related data to be monitored. The data is in plural formats and translated to a common format. The data is uploaded to a data collection center (DCE). Upon request, a portion of the data is formatted dependent on rights granted. The DCS comprises a data collector where the uploaded data is stored, and a publisher for publishing data collector data. Each site maintains its supply-chain data, a DTE for transferring the data to the DCS, input means for allowing a data collector query, and a display for displaying published data responsive to a query. The inbound data is monitored at the DCS. If a problem condition is detected, such as a shortage/surplus, an alert is asserted, e.g. by highlighting an Alert indicator. Upon alert indicator selection, details of the problem condition are displayed.

RELATED APPLICATIONS

This Application is a continuation of U.S. application Ser. No. 11/176,585, filed Jul. 7, 2005, which is a continuation of U.S. application Ser. No. 09/546,347, filed Apr. 7, 2000, now U.S. Pat. No. 6,947,903, which claims the benefit of U.S. Provisional Application No. 60/147,670 filed on Aug. 6, 1999, and is related to application Ser. No. 09/544,916, filed Apr. 7, 2000, now abandoned; the entire teachings of which are incorporated herein by reference in their entirety.

BACKGROUND OF THE INVENTION

A typical manufacturing supply chain includes an original equipment manufacturer (“OEM”), which designs and sells equipment such as computers or other electronic equipment. To keep costs down, OEMs often contract out the manufacture of at least some of the individual components of the product, such as electronic boards, to contract manufacturers (“CMs”). The CMs must obtain the parts with which to build the boards, such as resistors and integrated circuits, which are manufactured by component manufacturers or vendors. The components are typically not sold directly to the CMs but rather are sold through distributors.

For example, FIG. 1A illustrates a supply chain 2 as is well known in the art. Included in the supply chain 2 are a distributer 16, an original equipment manufacturer (OEM) 12, one or more contract manufactures 14, and one or more vendors 18. As indicated in the figure, each of these sites must communicate with one or more of the other sites as indicated by the arrows.

Each node or link in the supply chain, i.e., each OEMs, distributor, CM and vendor, typically maintains its own private database to track and control inventory, place orders, receive orders, enterprise resource planning (ERP), material requirements planning (MRP), etc. While these supply chain sites share some data, the data is typically maintained in incompatible formats in legacy databases.

The Electronic Data Interchange (“EDI”) standards have been developed to aid in the interchange of information to expedite business transactions by specifying a consistent data interchange format. Yet, in practice, how each supply chain site deals with its external environment, i.e., vendors, CMs, customers, has often been archaic and inconsistent.

Supply chain management is difficult because it depends on the axiom that a business has fundamentally correct processes. Unless the foundation for activity is well thought out, managing the chain further aggravates a company's environment. For example, not all of the information needed may be available on the legacy databases. Often, teams of programmers are utilized to implement custom design changes to these legacy databases that become overwhelmingly complex. Whether these changes are implemented by outside consultants or by in-house staff, lack of clear project goals, effective monitoring and performance review constantly plague the process.

SUMMARY OF THE INVENTION

The present invention eliminates much of the confusion which results from redesigning one or more complex legacy systems. Instead, legacy systems are left intact, and a data transfer engine (“DTE”) is installed at each site. The DTE monitors the local system continuously, and takes whatever information is available. While a complete picture of the supply chain may not be provided if not all information is available, for example, if a certain attribute is not tracked at a particular site, the DTE takes whatever data is available, cleans up the data, and formats the data into a common format acceptable to a data collection site. The DTE then transmits or uploads the data to the data collection site, which is preferably a distributor or an OEM.

While some custom programming is required to extract the proper information and clean it up, no change to the existing business process is required. The programming that is required for extracting and cleaning the data is minimal compared to the major rewriting or restructuring necessary for previous known methods.

The ability to collect data and lay it out before a user in logically configured views where sources and demands are made visible, and where every view is within two or three mouse clicks away, gives unprecedented power to OEMs and distributors to monitor, analyze and control the supply chain. The present invention provides information management and analysis capabilities at the component level for manufacturers, vendors and distributors operating in partnership to manufacture subassemblies that combine to produce a finished OEM product.

The present invention facilitates the relationships between the OEM, distributor, CMs and vendors (collectively, the “sites”) in the context of raw materials flow through the supply chain. A great benefit of the present invention lies in its ability to aggregate or collect, analyze, and inform multiple parties about the status of materials that move through their shared supply chain, directly influencing the success of each.

Accordingly, a method of monitoring supply chain activity throughout a plurality of supply chain sites, includes extracting, at each supply chain site, supply-related data to be monitored. The data is maintained in plural formats at the supply chain sites. The extracted data is then uploaded to and collected, from each supply chain site, to a data collection center or site, where it is stored in a common format. Upon a user request, a portion of the collected data is formatted, at the data collection site, into one of a plurality of views, responsive to criteria selected by the user, for presentation to the user, the portion of formatted data being dependent on access rights granted to the user's supply chain site. Finally, the formatted data view is published to the user's supply chain site.

The data collection center comprises a data collector in which the uploaded data is stored, and a publisher for publishing data from the data collector upon request. Each supply chain site has a data storage device for maintaining its own supply-chain data, a data transfer engine (DTE), for transferring the supply-chain data to the data collection center, input means for allowing a user to query the data collector, and a display for displaying data published by the publisher in response to a query.

In one embodiment, the data is translated at each supply chain site before uploading. Alternatively, the data is translated at the data collection site after uploading.

In one embodiment, each supply chain site is scanned at regular intervals for new or changed data. Upon finding new or changed data, the new or changed data are uploaded to the data collection site.

Plural formats can include, but are not limited to, spreadsheets, relational databases and text files. One skilled in the art would recognize that spreadsheets and databases themselves vary from vendor to vendor, and even two implementations using the same vendor's spreadsheet or database or text file will have data configured and/or formatted differently.

Data can include, but is not limited to, inventory data, purchase orders and lead time.

Data at the supply chain sites can be stored in legacy databases, that is, databases, spreadsheets, text files, and the like, which exist before implementation of the present invention.

In a further embodiment, the inbound data received from the multiple supply chain sites is monitored at the data collection site. If a problem condition is detected, such as a forecasted or present shortage or surplus, an alert is asserted, for example, by highlighting an alert indicator, such as an alert tab, on a user screen. Other possible alert condition indicators are, for example, a highlighted box or button, or a line of data in one of the screens corresponding to, say, a part number which is in an alert condition.

Upon selection of the highlighted alert indicator by a user, details of the detected problem condition are displayed. In one embodiment, the alert details are displayed in a bar graph. In another embodiment, alert details are displayed in a line graph.

In one aspect of the invention, animation is used to present data to a user. Specifically, data sets are shown within a historical basis and changes are shown evolving in animated real time.

Supply chain sites can include any or all of contract managers (CMs), vendors, distributors and an original equipment manufacturer (OEM).

In one embodiment, the data is encrypted before uploading.

Preferably, uploading the data is performed over the Internet.

In a further embodiment, materials requirements information are provided for a product at any or all stages in the product's lifecycle.

An analysis report is generated responsive to report selection by a user. The generated report is provided, responsive to user selection of report destinations, by emailing, printing, storing as a file or displaying on a monitor or a screen, the report.

Data is displayed in a window at a site's display according to a category selected by a user at the site, in response to authorization granted, for example, to the site, or to the user.

For each category, at least one analysis filter is selectable by the user for setting criteria to be used in filtering the data to be displayed. Filtering can include, for example, sorting and/or excluding certain data. Filters are preferably organized hierarchically.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and other objects, features and advantages of the invention will be apparent from the following more particular description of preferred embodiments of the invention, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the invention.

FIG. 1A is a block diagram illustrating a typical supply chain as known in the prior art.

FIG. 1B is a block diagram illustrating a typical supply chain in which the present invention is employed.

FIG. 1C is a schematic diagram illustrating that part of the present invention to be employed at each participating supply chain site.

FIG. 1D is a schematic diagram illustrating that part of the present invention to be employed at the data collection site.

FIG. 1E is a flowchart of the process employed by an embodiment of the present invention.

FIG. 2 is a screen shot of a login window employed by the present invention.

FIG. 3A is a screen shot of board data for all active boards, sorted by board number.

FIG. 3B is a screen shot similar to that shown in FIG. 3A, showing the associated pull-down menu.

FIG. 3C is a screen shot of board data resulting from the selection made from the pull-down menu shown in FIG. 3B.

FIG. 4 is a screen shot of board data for boards using parts sold by a particular distributor.

FIG. 5A is a screen shot of parts demand information for a particular distributor.

FIG. 5B is a screen shot similar to that of FIG. 5A, showing the associated pull-down menu.

FIG. 5C is a screen shot of parts information showing demand through lead time for a particular part, resulting from the selection made from the pull-down menu shown in FIG. 5B.

FIG. 6 is a screen shot of MRP data by board.

FIG. 7A is a screen shot of vendor data.

FIG. 7B is a screen shot similar to that of FIG. 7A, showing the associated pull-down menu.

FIG. 8 is a screen shot of sales data.

FIG. 9 is a screen shot of the reports ordering window.

FIG. 10 is a screen shot of a typical report sent to the screen.

FIGS. 11A-11C are screen shots of the alert window of the present invention.

FIG. 11D is a screen shot of an alternate alert window for use with the present invention.

FIG. 12 is a graph illustrating the use of animation by the present invention to present data.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1B illustrates a supply chain 10 environment in which the present invention is employed. An original equipment manufacturer (“OEM”) 12 designs products, assembles the products or contracts assembly out, receives sales orders (“SOs”) from customers and generates purchase orders (“POs”) to obtain the parts required to build the ordered equipment.

The POs may be sent to contract manufacturers (“CMs”) 14, who build, for example, boards which typically have 50 to 200 or more parts. The OEM 12 may contract with several CMs 14 to build the same board, and/or may contract with different CMs for different boards. Here, for example, several contract manufacturers CM-A through CM-D are depicted.

The CMs 14 themselves must obtain the required parts or components, such as resistors, capacitors, semi-conductors, knobs, indicators, hinges, switches, buttons, etc., either directly from the component manufacturers, or vendors 18, or more typically, from one or more distributors 16, who generally keep inventories in stock which they (the distributors) believe will satisfy foreseeable demand.

In addition, depending on how much of the manufacturing process the OEM 12 retains for itself, the OEM may also obtain parts directly from vendors 18 or through distributors 16.

Different components and boards have different lead times, which may be dependent on the availability or lead times of components, in the case of boards, or other factors, such as a particular vendor's or CM's build schedule. That is, different items take longer than others to order, design, produce, ship etc.

Each of the organizations or sites 12-18 in the supply chain 10 is concerned with what to build and, given lead times and existing inventory, when to build and ship, so that the equipment ordered from the OEM 12 can be built and delivered in a timely fashion.

The present invention makes information regarding current orders, lead times, parts, etc. available to some or all of the supply chain sites, by collecting the data at a central site 16A and selectively publishing that data to the other sites upon request. In the embodiment of FIG. 1B, the central site 16A is located at the distributor 16. In practice, the actual location could be anywhere. In one embodiment, it is controlled by the OEM 12.

FIG. 1C is a schematic diagram illustrating that part of the present invention to be employed at each participating supply chain site. Box 19 represents any of the sites 12-18 of FIG. 1B. Each organization or site 19 typically maintains its own data storage devices containing legacy information such as enterprise resource planning (ERP) data, material resource planning (MRP) data, purchasing information, inventory, etc.

This information may be maintained, for example in text files such as ASCII files 24, spreadsheets 22, and/or databases 20. The formats of such data may be proprietary or customized. One site might use one type of spreadsheet while another site uses another kind of spreadsheet. Similarly, one site might use a particular database while another site uses a different database. Even databases bought from the same database provider may be customized so that similar data is maintained differently at different sites. Furthermore, some sites may not retain certain data, having deemed it unimportant.

Before the development of the present invention, with all of these different legacy systems in place at the various supply chain sites 19, OEM verification of data, such as purchase orders and inventory, was extremely difficult. The quality of data from the various sites 19 is clouded because there is no lowest common denominator.

In the past, teams of Information Technology software engineers have typically re-engineered the existing systems. This can be a huge data conversion and software integration effort, even at a single site, and becomes much more problematic when trying to make the data uniform across independent contract manufacturers and vendors who likely will not be eager to redesign their business method and database. Even the Electronic Data Interchange (“EDI”) specification does not provide enough structure to ensure that users use it properly.

On the other hand, the present invention takes data as it exists on each site's legacy system. Data from all of the sites is collected at the center hub 16A, or data collection site, which is preferably the distributor 16 or the OEM 12, and selectively published to the sites 19.

Data is retrieved from each site 19 by installing at each site a data transfer engine (DTE) 26, preferably implemented in software. The DTE takes data in any size or format, including various databases 24 and/or spreadsheets 22 and/or text files such as ASCII files 20, and corrects, translates and formats the data into “clean” data. In one embodiment, the DTE looks for changes to data and uploads new data to the data collection site 16A upon finding a change. Alternatively, the DTE may upload data upon some other trigger such as the end of a time period, or may upload data in response to a request from the data collection site 16A.

Communication between a site 19 and the data collection site 16A can be by any well-known means 40, for example, over the Internet or via a dial-up connection, or via a virtual private network (VPN). In one embodiment, the data is formatted using a formatting language such as XML. In one embodiment, all data transfers are encrypted. Web servers and browsers can also be employed.

The present invention is thus passive in that it takes whatever data a site has, for example, extracting data from any popular database, such as Oracle, SAP, Sybase, Bahn, etc., or from spreadsheets such as Lotus, or any data reduced to an ASCII or EDI file, or any other formatted file. No redesign or re-engineering is required.

FIG. 1D is a schematic diagram illustrating the components of the present invention employed at the data collection site 16A. A data collection database 34 or an equivalent data storage system collects the data sent by each DTE 26 (FIG. 1C). A publisher 36 receives query requests from the various sites 19, and depending on the access rights granted to a particular requesting site, formats and publishes the relevant supply-chain data to the requesting site, which then displays the data in a logical format as described below on a monitor 28 (FIG. 1C).

Each site 19 which accesses the collected data requires one or more computers, each of which typically comprises a monitor 28 for showing the requested information or report, a keyboard 30 for entering certain information, and a mouse 32 for navigating through the screens.

FIG. 1E is a flow chart 70 illustrating the general process of an embodiment of the present invention. A typical supply chain site 19 is shown on the left side of the figure while the data collection site 16A is shown on the right side of the figure. Where possible, reference numbers correspond to those used in FIGS. 1C and 1D.

The data transfer engine 26 extracts data in step 72 from various formatted data, for example a database 20, an ASCII text file 24, or a spreadsheet 22. After the data is extracted, it is translated to a common format in step 74 in one embodiment. After translation in step 74, the data is uploaded in step 76 to the data collection site 16A were it is received in step 78. Alternatively, translation could be done after upload. The received data is then collected and stored in, for example, a database 34 (step 80).

This process of data extraction uploading and collection of the data at the data collection site 16A can be preformed regularly, upon the expiration of the predetermined time period or, for example, when a change in the data is detected at the supply chain site 19.

At some later time, a user requests certain data at step 82, at the supply chain site 19. This request is forwarded to the data collection site. In response, the data collection site 16A formats the data (step 84) and publishes the formatted data (step 86) to the supply chain site 19. The published data is then view or stored or printed, as in step 88.

FIG. 2 shows a login or “splash” window 50 as might appear on a site's computer monitor 28 upon a user logging into the data collection site 16A. The login window 50 builds on the theme of collaboration between the contract manufacturers that produce the foundation of an OEM's products. Preferably, images containing company names and/or logos or trademarks are displayed for the OEM at 51, and for the contract manufacturers at 53. In one embodiment, these images 51, 53 are links to connect directly to the specific company. In the sample screen, the distributor, whose logo 52 is displayed at the top, is the data collection site.

Text entry blocks 55, 57 are provided for entering a user identification (ID) and password respectively. After entering these, a user clicks on “OK” 59 to have his ID and password verified, or clicks on “Exit” 61 to exit.

In the example embodiment, once a user has properly logged in, all data pertains to the specific OEM. In other embodiments, a distributor might select from among a plurality of OEMs, for example, via a pull-down menu. In yet another embodiment, an OEM dealing with multiple distributors could select from among a plurality of distributors.

FIG. 3A is a screen shot 100 of circuit board data for all active boards, sorted by board number. In one embodiment, this view 100 is the default screen shown to a user after a successful login.

Common to all screens after logging in is the set of tabs 102 which allow the user to navigate quickly to the desired information. When the “Boards” tab 102A is selected, a list of filters 104A specific to the display of board-related information is displayed. In the view 100 shown, the filter list 104A is divided logically into two groups.

The first group of filters, labeled “Board Type”, comprises six filters in the embodiment shown. By selecting a particular filter, the user can choose to see only boards of a particular status, for example, boards that are classified as one of Active, Pre-production, Engineering or Obsolete. In addition, in this particular embodiment, Active boards can be sorted either by board number (“Active by Board”) or by contract manufacturer (“Active by CM”). Finally, selecting “Combined” shows all boards. It will be obvious to one skilled in the art that other criteria for selecting and sorting boards can be provided. Thus, materials requirements information may be viewed for products at all stages in their lifecycle.

In the screen 100 of FIG. 3A, the “Board Type—Active by Board” filter has been selected. That is, the user has requested information on all boards having a status of “Active”. All “Active” boards are listed in order according to the OEM's board number.

The requested information for each “active” board is retrieved from the data collection site's database 34 (FIG. 1C), sent by the publisher 36 to the requesting site, and displayed on the requesting site's monitor 28 in various columns or fields. This data may include, for example, the board's OEM part number 106, name 108, manufacturer 110, status 112, and projected delivery date 114, 116 for the corresponding manufacturer.

Because the user has selected the “Active by Board” filter, boards are listed alphanumerically by board part number 106. Note that each entry in the board column has an arrow 107 for viewing a pull-down menu, described below with respect to FIG. 3B.

In the “Board Name” field 108, a board name is provided if it is known to the system. The “Manufacturer” field 110 shows the name of a CM that manufactures the board. Note that each manufacturer can assign the same board a different name, or not assign any name at all.

The “Status” field 112 shows the status of each board. Of course, available statuses can be different according to the particular needs of the users and application, but in the illustrated embodiment, the available statuses are “Active” for boards which are currently utilized by the OEM, “Pre-production” for boards which are in final approval status by the OEM, that is, boards which are normally near complete, “Engineering” for boards which are in a pre-prototype or prototype stage and not yet used in production, and finally “Obsolete” for those boards that are not used in any present OEM machines, but which could, for example, still be made for field upgrades, probably in limited quantities.

The “Year” 114 and “Week” 116 fields show the projected delivery date for the particular board from the CM shown.

Note that a board can be listed in multiple lines, one line for each distinct set of, in this example, board name, manufacturer, status, year and week. For example, in FIG. 3A, the first three lines show a board having a part number of 200-520-921. The first line indicates that CM-KK is one of the manufacturers of this board and is currently building this board.

The second line shows that a second contract manufacturer, CM-NN, also manufactures this board, and in addition calls the board a “Fiber Drtr Board.”

The third line is again for boards ordered from the first CM, CM-KK, but for a different scheduled delivery week.

Finally, a footer 118 displays the currently selected filter, here “Board Type—Active by Board.’

FIG. 3B shows a pull-down menu 120 which appears when the user holds down the mouse button over an arrow 107A in the board column 106. Selecting one of the three menu views displays detailed information for the corresponding board.

FIG. 3C shows the displayed view 130 resulting when the “MRP for ALL CMs” view is selected from the menu 120 for part number 200-520-921, i.e., any of the first three lines of FIG. 3A.

A split screen, well-known to those skilled in the art, to allow the display of non-contiguous portions 132, 134 of a view, is shown. Displayed data includes, for example, “Board” part number 136, “CM” 138, “Board Name” 140, “MRP Date” 142 and “Origin” 144 columns. Board Name corresponds to the same column of FIG. 3A. MRP Date refers to the date on which the CM must receive parts from the distributor or the component manufacturer. Origin indicates the location of the CM's plant where the board is actually being manufactured (as in Cork, Ireland).

FIG. 4 shows a view 150 displayed when the “Boards Only” filter is selected under the “Using IEC Parts” in the filter section 104. This view 150 shows data about boards using parts carried by a particular distributor, in this case IEC. Of course, if there were more than one distributor, additional filters could be available to select boards using parts handled by those distributors as well. The “Board” 152, “Board Name” 154 and “Status” 156 columns correspond to the similarly named columns of FIG. 3A. If there were more than one OEM, for instance if the data were being reviewed by a distributor who deals with multiple OEMs, additional filters could be available to list boards of particular OEMs.

Selecting “Boards and Parts” provides an exploded view (not shown) of boards with additional detail based upon the Bill of Material, or BOM, for each board.

The view 160 of FIG. 5A is displayed upon the selection of the Parts tab 102B. A new list of filters 104B, pertaining to parts, is available in filter partition 104. Here, the “IEC Parts Demand” filter has been selected, as indicated by its being highlighted and by the footer text 118.

As with the parts views of FIGS. 3A-3C, several columns are displayed, including the OEM's part number 162, the vendor or manufacturer of the part 166, the vendor's part number 168 for this part, the vendor's lead-time (“Lead weeks”) for this part, the “Buffer” 172, indicating an amount of inventory quantity, if any, that has been negotiated between the OEM and distributor/component manufacturer to be kept on hand above and beyond committed stock, a “NCNR” indicator 174 which indicates whether the item is non-cancelable, non-returnable, and a field 176 labeled “Celestica Part.” Each additional CM which manufactures this part has a corresponding column (not shown), which can be scrolled into view using the scroll bar 177. Each of these CM columns, such as column 176, shows the particular CM's part number for the corresponding part.

Note that customer part numbers, as these are commonly referred to, are created by the CM or OEM, and have significance that is beyond the current transactional circle. Thus, a CM may have a customer part number that may apply to other jobs in addition to the one they perform for the current OEM. This enables the CM to sort or use this data “companywide”.

In additional, there may be more than one vendor of a particular part. For example, the OEM's part number 004-368-101 is provided by two different vendors, as shown in the second and third lines of FIG. 5A. Here, the OEM feels these parts are identical and can be “second sourced” using the same number.

In fact, lines 5 and 6 of FIG. 5A indicate that two slightly different numbered parts (e.g., DS1232S/OEM-ZZ and DS1232S/TR/OEM-ZZ) from the same vendor (VEND BB) may be used to satisfy the distributor's part. Each part is shown in its own line.

Several filters 104B are provided. For example, sorting is available for parts profiles for a particular distributor such as IEC by NAED (a generic industry-wide number assigned by the National Association of Electrical Distributors), by manufacturer, or by the OEM's part number or part class. A part class is, for example, a class of components, such as resistors, perhaps of a certain wattage.

Cross reference filters are also available for OEM numbers and for each contract manufacturer. Finally, parts viewed with a parts profile can be sorted by “Resale Price”, which is the resale price that the distributor or component manufacturer (the vendor) charges the CM.

As can be seen, other filter groups are available, such as “Lead Times/Buffers,” in which parts are sorted, first by lead time (highest to lowest), then by buffer (highest to lowest), then by either OEM-ZZ, NAED or vendor part number, as selected. Filters are organized hierarchically and the upper levels may be closed or opened (expanded) by the user to simplify viewing.

Another filter class is Inventory. Inventory levels can be illustrated by quantity, part type (fully cross referenced), and by chain participant, i.e., by CM, distributor, or component manufacturer.

Yet another filter class is Purchases. Purchases can be referenced as backlog by the supplier, i.e., the distributor, or a vendor.

Selection of the IEC Parts Demand filter shows, going forward, which parts are due out in what weeks.

An IEC Parts Admin selection is also available to provide administrative functions to privileged users.

As FIG. 5B shows, each line has a corresponding pull-down menu 180, through which a user can select detailed information such as “Demand Through Lead Time” or “Demand Through Next Quarter.”

In FIG. 5C, the user has selected “Demand Through Lead Time” for the OEM's part number 012-000-021, and specifically, the manufacturer's part number DS1232S/TR/OEM-ZZ, which has a lead time of 6 weeks.

Detailed information for this part number is displayed, including, for example, MRP Origin 192, which has the same meaning as “Origin” 144 in the screen of FIG. 3C, the contract manufacturer 194 and those OEM's boards 196 which use the OEM's generic part 012-000-021, or, alternatively, boards that specifically use the vendor's DS1232S/TR/OEM-ZZ part.

The Week 31-35 columns 198 show quantities related to the part number, needed for each week for the particular board. Additional week columns are off-screen, but can be scrolled into view.

Totals for each week are shown in the bottom row 199.

FIG. 6 is a screen view 200 of MRP data by board, obtained by selecting the MRPs tab 102C. A variety of MRP-related filters 104C are available, providing a large degree of analysis of the supply chain data. Using these filters, for example, a match between the OEM's demand and the CM's demand as placed on the distributor/vendor can be easily shown.

Here, “OEM-ZZ (C)→CM-LL, MRP by Board” has been selected, indicating a desire by a user to review all boards ordered from contract manufacturer CM-LL for orders placed on it by, for example, the branch of the OEM indicated by “(C)”.

The data shown includes each qualifying circuit board part number 206, the name, if any, given to each circuit board 208, and quantities 210 for, in this example, each week.

Similarly, FIG. 7A is a screen view 220 of vendor data, displayed when the Vendors tab 102D is selected. Various filters 104D, available according to vendor, are selectable. The selected filter, VEND-DD, is highlighted. Data shown includes circuit board part number 222, NAED number 226, contract manufacturer CM-KK's part number 228, a manufacturing part number 230, and the manufacturer name 240.

In FIG. 7B, a pull-down menu 242 is available for each OEM part number, by clicking on the arrow 224 (FIG. 7A) next to the part number, allowing the user to see all boards using that part.

FIG. 8 is a screen view 250 of sales data, which is displayed when a user selects the Sales tab 102E. A variety of sales-related analysis filters 104E are provided. In the illustrated example, “Sales—By NAED Number” has been selected. Several columns of sales-related data are displayed, including CM 252. The first column 252 is labeled with the name of the OEM, here “OEM-ZZ”. Preferably, each account or location for a CM has a different name. For example, CM-LL8 is a specific account for vendor CM-LL.

Other columns include order number 254 from the CMs to the distributor, the NAED-assigned part number 256, discussed previously, the vendor's part number 258, customer part number (PN) 260 corresponding to the OEM's part number and a quantity ordered 262 and quantity shipped 264. Note that the OEM is normally that entity that has “the customer number”.

A CM Terms Admin selection allows an authorized user to perform administrative functions. Such functions can serve to quantify business rules to a CM, including such terms as scheduling, buffer inventory and liability.

FIG. 9 is a view of the reports ordering window 270, displayed upon selection of the Reports tab 102F. A variety of analysis reports 104F, arranged hierarchically by topic, is available. Topics can include, but are not limited to, analysis reports, monthly shipment reports and day sales outstanding (DSO) reports.

A selected report can be sent to the screen, to a printer, to a file, or to a person via email, by selecting the respective button 272, 274, 280, 286. “From page” and “To” fields 276, 278 allow the printing of only selected pages. File Name and File Type fields 284, 288 allow the designated report to be named and saved in a variety of formats. To, cc:, Subject and message fields, 288, 290, 292 and 294 respectively, allow the user to specify recipients of the report, and to add a subject and remarks.

Note that in FIG. 9 a lead time analysis report has been selected in the filtered 104 f, and send report to screen 272 has been selected.

FIG. 10 is a screen shot 290 of a typical report sent to the screen for the lead time report requested in FIG. 9.

The present invention traps conditions that will create problem situations for the networked partners. When looming conditions of surplus or shortage become apparent by looking ahead at supply and demand, an alert is raised by coloring the Alert tab 102G bright red. Of course, in alternate embodiments, a flag or other icon, or, for example, an audible signal, could be used as well to indicate alert conditions. The screen 300A shown in FIG. 11A is displayed upon selection of the Alert tab 102G.

The alert window 300A is divided into two sections. The upper portion 302 lists current alert conditions by alert type 304, origin 306, CM 308, the OEM's number for the affected board 310, the OEM's part number for the actual part causing the alert of column 312, the manufacturer of the part 314 and the manufacturer's part number 316.

The lower portion 318 of the window 300A shows details of the currently selected alert condition 302A in graphical form. Bars are preferably color coded. For example, bar 322A could be light blue to indicate some status, while bar 322B could be green to indicate another status, bar 322C could be yellow to indicate yet another status, and bar 322D is red to indicate alert status. Bar 321, indicating lead time, is dark blue. While different colors can be used, red is preferred for alert conditions to catch a user's attention. In particular, red preferably indicates trouble on a lead time for a defined part number. Other colors are for differentiation of lead-time periods.

In one embodiment, a bar is red to indicate that a product is overdue and not received. The left side of a bar indicates when a product is first due, while the right side of the bar indicates when all product is due. A green bar, on the other hand, indicates the period during which product is expected to be timely received. The left side of a green bar coincides with placement of an order. If a full shipment is received the entire bar is green. The right side of the green bar indicates the final receipt of a product.

Liability windows (LW) are also shown, defining a period of time within which the distributor will be liable for the procurement of the subject part if an order is cancelled. This period is indicated by the width of the LW bar, which in one embodiment is yellow. If the distributor cancels outside that timeframe, then no liability exists. Liability windows can differ among part number and by vendors. When a user clicks on a LW bar, a number of day(s) of the LW appears in a pop-up window. Since this number defines the LW, the distributor can cancel any quantity due without liability if such cancellation is for product due beyond the right side of the LW bar.

As this example suggests, an unexpected production plan increase is impacting the supply chain. Here, the problem week, week 13 of 1999 as indicated by bar 319, is viewed in relation to the purchases that have been made for that part. Details of each bar include, for example, purchases, deliveries, and delays that can conspire to aggravate a demand condition.

Individual line items, such as 302A or 302B, can also be color coded to indicate a particular status.

Similarly, any of the lines containing boards or part information, as depicted for example in any of FIGS. 3A-8, can also be color-coded to indicate status, in particular, an alert condition. Either the background or the text itself can be color coded.

In one embodiment, navigating to the screens depicted in FIGS. 11B, 11C and 11D is done by clicking the right mouse button on a blank part of the screen of FIG. 11A. A pop up window appears (not shown). The user selects “sales” to go to the screen of FIG. 11B, or “quantities” to go to the screen of FIG. 11C or FIG. 11D.

Also, by clicking on a bar 322D on the graph 318, the screen 300B of FIG. 11B is displayed. This view displays the same problem event in the context of sales of the product that can yield an unattainable obligation unless measures are taken immediately.

In FIG. 11C, the bottom portion 330 of the screen 300C shows quantity levels for the problem part. Preferably, the different quantities are color-coded. The available data analysis can make visible the resulting expected shortage that too often occurs, and meets with an untimely response that has already broken the efficiencies of the manufacturing process.

Current MRP is the MRP data that was last received. Previous MRP is the MRP information received just before the last. Changes to the MRP can be viewed here. In this example, the previous MRP called out for 500 pieces, while the current calls out for 1000 pieces. Thus, a 500-piece shortage has been created.

On-hand is inventory, and is preferably categorized by each distributor, the CM's and the vendors. It is important to have access to all stock positions on an ongoing basis.

FIG. 11D presents an alternate alert screen view for use in one embodiment of the present invention. Panel 352 allows a user to view alerts pertaining only to certain vendors or parts, etc. In addition, rather than using bars to portray data, a graph 354 is used.

FIG. 12 is a graph 400 illustrating the use of animation by the present invention to present data. The present invention is based upon state of the art technologies that lend themselves to analysis and modeling of trends. This affords a novel opportunity to put the aggregate data to use in viewing the dynamics of the supply chain.

The graph 400 can be viewed by selecting an icon in a toolbar (not shown). By clicking on a “play” button (not shown) next to the graph 400, the user is presented with multi-dimensional views of the data, including animations of the data over time, which enable the discovery of conditions that can be smoothed to the advantage of all partners in the supply chain.

In FIG. 12, the sum of orders is negative when there are not enough orders to fulfill requirements.

With the analysis tools described above, if a vendor does not have a sufficient quantity of parts, the distributor can easily find a CM who has surplus parts to sell to another CM who needs the parts.

The present invention provides feedback to CMs and vendors, pointing out their weak spots, and showing where they can strengthen their position by cleaning up their data.

While the present invention has been shown in a distributor's supply chain, it can also be used anywhere there is a supply chain, such as in retail, wholesale, the food industry, etc.

It will be apparent to those of ordinary skill in the art that methods involved in the present system for monitoring a supply chain may be embodied in a computer program product that includes a computer usable medium. For example, such a computer usable medium can include a readable memory device, such as a hard drive device, a CD-ROM, a DVD-ROM, or a computer diskette, having computer readable program code segments stored thereon. The computer readable medium can also include a communications or transmission medium, such as a bus or a communications link, either optical, wired, or wireless, having program code segments carried thereon as digital or analog data signals.

While this invention has been particularly shown and described with references to preferred embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the scope of the invention encompassed by the appended claims. 

What is claimed is:
 1. A data importation method comprising: receiving first product data in a first format; comparing the first product data with second product data previously received; reviewing results of the comparison to determine whether there is a problem with the first product data; changing a format of the first product data to a standard format; comparing the standard format first product data with third product data, the third product data corresponding to the second product data having format changed to the standard format; placing the standard format first product data in a category based on the comparison of the standard format first product data with the third product data; and generating statistics based on the comparison of the standard format first product data with the third product data.
 2. The method of claim 1, wherein placing the standard format first product data in a category comprises placing the standard format first product data in an identical products file.
 3. The method of claim 1, wherein placing the standard format first product data in a category comprises placing the standard format first product data in a new products file.
 4. The method of claim 3, further comprising: retrieving original supplier data for an original supplier product; normalizing at least one company in the retrieved supplier data; looking up the original supplier product in a product database to determine whether data corresponding to the original supplier product has been provided by other suppliers; locating a template for the original supplier product corresponding to the retrieved supplier data; normalizing at least one attribute from the retrieved supplier data by using the template; defining normalized product data as the supplier data having the normalized at least one company and the normalized at least one attribute; and inserting the normalized product data into the product database.
 5. The method of claim 4, wherein the step of normalizing at least one company comprises normalizing vendors and manufacturers associated with the product.
 6. The method of claim 4, wherein the looking the product up step comprises determining whether the retrieved product data already exists in the product database.
 7. The method of claim 6, further comprising: comparing the normalized at least one attribute with existing attributes; selecting correct attribute values; and updating the normalized product data in the product database with the correct attribute values.
 8. The method of claim 4, further comprising a step of updating attribution definitions before the step of inserting the normalized product data.
 9. The method of claim 4, further comprising: identifying a category associated with the original supplier product; retrieving original supplier data for other original supplier products; and optionally assigning to the located template all products in the other supplier original products corresponding to the identified category.
 10. The method of claim 1, wherein placing the standard format first product data in a category comprises placing the standard format first product data in a changed products file.
 11. The method of claim 1, wherein placing the standard format first product data in a category comprises placing the standard format first product data in a deleted products file.
 12. The method of claim 11, further comprising: retrieving product data from the delete products file; looking up the retrieved product data in the product database; deleting from the database the retrieved product data, which corresponds to a first supplier, when a product corresponding to the retrieved product data has not been deleted for all other suppliers.
 13. The method of claim 1, wherein placing the standard format first product data in a category comprises placing the standard format first product data in a faulty products file. 